home *** CD-ROM | disk | FTP | other *** search
/ Belgian Amiga Club - ADF Collection / BS1 part 27.zip / BS1 part 27 / OcteMedProV5.0.adf / Docs / MMD_FileFormat.doc < prev    next >
Text File  |  1993-06-29  |  3KB  |  62 lines
  1. -----------------------------------------------------------------------------
  2.         MED/OctaMED MMD0/MMD1/MMD2 file formats
  3.         written by Teijo Kinnunen (30.05.1993)
  4.         Revision 2
  5.  
  6. $VER: MMD_documentation 2 (30.05.1993)
  7.  
  8. -----------------------------------------------------------------------------
  9.  
  10. Background
  11. ~~~~~~~~~~
  12. A  couple of years ago, when programming MED V2.1, I needed a file format
  13. for MED modules. The only "module" format in MED V2.0 was the Sng+samples
  14. format. Although it produced compact files, it was very difficult and
  15. tricky to read in. Therefore, I designed a new file format that would be
  16. easy to use in module player programs etc. This file format was named
  17. 'MMD0' (Med MoDule 0). The  limitations in the MMD0 block format forced me
  18. to create a new file format for OctaMED Professional, this format is
  19. 'MMD1'. It's mostly the same as MMD0, except the block structure is
  20. different. Another new format is called 'MMD2', this extends some of the
  21. old limits and provides a couple of new features
  22.  
  23. Design concepts
  24. ~~~~~~~~~~~~~~~
  25. One of the main goals was to make MMD's (MED modules) as extensible as
  26. possible. This would have been easy to implement with IFF-style chunks.
  27. However, this method is obviously not the best for play-routine use.
  28.  
  29. Therefore, MMD's are implemented in quite an extraordinary way. They
  30. consist of structures (similar to C structs) and pointers. In a module file
  31. pointers are defined as offsets from the beginning of the module. This way,
  32. a particular structure can be read just by Seek()'ing using the pointer as
  33. the offset from the beginning of the file. When a module has been read into
  34. memory, it has to be relocated before it can be used (the relocation is
  35. done simply by adding the address of the module to the pointers).
  36.  
  37. As with the Amiga OS, a MMD file does not contain absolute addresses.
  38. There's a module header structure at the beginning of the file.  This
  39. structure contains pointers to different parts of the module.  And you
  40. *MUST* use these pointers. You may NOT expect that the song structure is at
  41. offset $00000034, for example. Although it usually is, this may change in
  42. future releases. In addition, it's possible that a structure even doesn't
  43. exist (the structure pointer is NULL).  Therefore, you *MUST* check the
  44. structure pointer before accessing the structure. Finally, when writing
  45. MMD's you *MUST* set undefined/reserved fields to zeros.  More finally, you
  46. *MUST* align all structures to even boundaries! (I forgot the alignment in
  47. MED V3.00 save routine, resulting Guruing modules under some conditions :-(
  48.  
  49. The module header
  50. ~~~~~~~~~~~~~~~~~
  51. This structure must exist at the beginning of each MED module file. Each of
  52. the structure members are described FULLY on the programmers disk that is
  53. available from RBF Software. (See Programmers drawer)
  54.  
  55. In multi-modules, there are header structs for each song. (The subsequent
  56. header pointers can be found from the expdata structure. Multi-modules
  57. should have the same smplarr pointer in every header.) Older MEDs which
  58. don't recognize multi-modules consider a multi-module as an ordinary module
  59. (only the first song is loaded).
  60.  
  61.    Please see the Programmers drawer for details on obtaining FULL info.
  62.